Ian & Stuart's Australian Mac: Not for Sale

home *** CD-ROM | disk | FTP | other *** search

/ Ian & Stuart's Australian Mac: Not for Sale / Another.not.for.sale (Australia).iso / hold me in your arms / Virus / List of Mac Viruses < prev

Wrap

Internet Message Format | 1989-12-20 | 71KB

From: David.J.Ferbrache <davidf%CS.HW.AC.UK@IBM1.CC.Lehigh.Edu> Subject: Mac Digest Date: Thu, 11 May 89 11:36:52 BST One of five! List of known Macintosh viruses This digest includes a list of all known Apple Macintosh viruses together with a selection of reports (published in virus-l) describing the virus, its symptoms, propogation and detection. The known viruses are: 1. Peace (Drew/Macmag) virus designed to display a message of world peace on March 2nd 1988 and then delete itself. The virus propogates by inserting an INIT 6 (Name "RR") into the system file. This virus does not infect application programs but propagates only to system files present on hard or floppy disks. 2. nVIR virus probably the most ubiquitous of all Mac viruses, seven variants of this virus are known to exist. nVIR spreads via infected system files and applications. When an infected application is executed a INIT 32 resource is added to the system folder, when the Mac is subsequently rebooted the virus becomes resident in memory. Thereafter all application programs started are infected (including the finder/multi-finder) through the addition of a CODE 256 resource. The virus is so named for the nVIR resources added (in addition to INIT/CODE) to the system file or application program. The nVIR A variant incorporates a counter which is decremented from 1000 by 1 each reboot, and by 2 each time an infected application is run. When the counter reaches zero nVIR A will say "Dont panic" if MacinTalk is installed, or beep if not. This occurs 1 in 16 reboots, 1 in 8 aplication runs. The nVIR B variant beeps (does not use Mac-in-talk) 1 in 8 reboots, and 1 in 4 application startups. Variants of this virus allegedly exist which when activated will delete a random file from the system folder. The further variants of the nVIR virus consist of slight modifications to the name or number used for the auxiliary nVIR resources, thus: a. Hpat - renumbered code resource, nVIR changed to Hpat. Otherwise symptoms as for nVIR B. b. AIDS - renamed code resources, nVIR changed to AIDS. Otherwise symptoms as for nVIR B. c. MEV# - renamed code resources, nVIR changed to MEV#. Otherwise symptoms as for nVIR B. The characteristic resources for the nVIR A/B, Hpat and AIDS viruses, which can be seen in infected system files or applications using a resource editor, are: Virus Common to both System file Application nVIR A nVIR 1 (378 byte) INIT 32 (366 bytes) CODE 256 (372 bytes) nVIR 6 (868 byte) nVIR 0 (2 bytes) nVIR 2 (8 bytes) nVIR 7 (1562 byte) nVIR 4 (372 bytes) nVIR 3 (366 bytes) nVIR 5 (8 bytes) nVIR B nVIR 1 (428 byte) INIT 32 (416 bytes) CODE 256 (422 bytes) nVIR 6 (66 byte) nVIR 0 (2 bytes) nVIR 2 (8 bytes) nVIR 7 (2106 bytes) nVIR 4 (422 bytes) nVIR 3 (416 bytes) nVIR 5 (8 bytes) Hpat Hpat 1 (428 byte) INIT 32 (416 bytes) CODE 255 (422 bytes) Hpat 6 (66 bytes) Hpat 0 (2 bytes) Hpat 2 (8 bytes) Hpat 7 (2106 bytes) Hpat 4 (422 bytes) Hpat 3 (416 bytes) Hpat 5 (8 bytes) AIDS AIDS 1 (428 byte) INIT 32 (416 bytes) CODE 256 (422 bytes) AIDS 6 (66 bytes) AIDS 0 (2 bytes) AIDS 2 (8 bytes) AIDS 7 (2106 bytes) AIDS 4 (422 bytes) AIDS 3 (416 bytes) AIDS 5 (8 bytes) MEV# not confirmed, but assumed to demonstrate the same pattern as AIDS. 3. Scores virus Scores infects the system folder, applications, note pad and scrapbook files. When an infected application is run the virus will infect the system file, note pad and scrapbook file. In addition two invisible system files are created named Scores and Desktop. Two days after system infection the virus begins to spread to application programs. Any applications run are infected, applications with "VULT" and "ERIC" resources are specifically targetted. If such an application is run the virus will cause a system error after 25 minutes of use. After 7 days the final phase of virus activity is entered: 15 minutes after a "VULT" application is started the virus will cause any writes to a disk file to return a system error. Other than the extension of application files and memory usage Scores does not damage applications or destroy data. The characteristic resources of this virus are: Scores System file INIT 6 (772 bytes), INIT 10 (1020 bytes), INIT 17 (480 bytes), atpl 128 (2410 bytes), DATA -400 (7026 bytes) Application CODE n+2 (7026 bytes) [where n is the number of the last application code resource] 4. INIT 29 virus INIT 29 is activated when an infected application is run or selected, the system file is then infected, and the virus patches the Open resource file trap. Subsequently any action which opens the resource fork of a file will cause that file's fork to be infected. This infection takes the form of the addition of a 712 bytes code resource (numbered with the lowest free code resource number) to applications or an INIT 29 to other files. Note that this virus does not require an application to be run to cause infection. Only infected system files or applications will spread the virus, although a large number of other files may be infected. A characteristic of this virus is its attempt to infect the desktop on a newly inserted disk, causing the message that "The disk needs minor repairs" 5. ANTI virus ANTI is the first virus for the Mac which does not add a resource to the infected file. The virus instead appends its code to the main code resource of the application, and patches the code to ensure its execution prior to the application. The virus adds 1344 to the CODE 1 resource of the application file being infected. Again it is not necessary to run an application to cause infection, however Anti is less infectious as it does not infect the system file, and thus the infection will only be activated when an infected application is run. Due to a bug Anti will not spread under Multi-finder. 6. Dukakis virus One of the more unusual viruses, this is a Hypertext virus which propogates between Hypertext stacks. When an infected stack is executed the openStack handler displays a message "Dukakis for President", it then install the virus into the home stack, from where it will infect each stack as it is opened. This concludes a brief overview of the known Mac viruses, appended at the end of this article are a selection of articles appearing in virus-l or on various bulletin boards over the past year. Hopefully this article (the first of five) has done something to increase the level of awareness by users of the threat posed by Mac viruses, it may also save people hunting through backissues. The next installment will be targetted at IBM PC viruses, it will be slightly longer since it should describe about 70 variants of 17 viruses. Following this will be a section on Atari ST viruses, Commodore Amiga viruses and finally Apple II viruses. This series is a stopgap until I can publish a formal catalogue of known viruses (due out at the end of June), with standardised description formats. Please, please report any viruses you find which do not appear in these lists. There are a large number of experts in the field (amongst which I don't yet count myself!) who can arrange for the rapid analysis and disassembly of new viruses. ------------------------------------------------------------------------------ Dave Ferbrache Internet <davidf@cs.hw.ac.uk> Dept of computer science Janet <davidf@uk.ac.hw.cs> Heriot-Watt University UUCP ..!mcvax!hwcs!davidf 79 Grassmarket Telephone +44 31-225-6465 ext 553 Edinburgh, United Kingdom Facsimile +44 31-220-4277 EH1 2HJ BIX dferbrache ------------------------------------------------------------------------------ MACMAG VIRUS Subject: MacMag virus infects commercial software According to an article in this morning's San Jose Mercury News, the "DREW" INIT-virus has been found to have infected a commercial software product. The virus, which was a "benign" time-bomb designed to display a message of world peace on March 2nd, is present on disks containing Aldus FreeHand. The virus was inadvertently passed to Aldus by Marc Canter, president of MacroMind Inc., which makes training disks for Aldus. Canter visited Canada some time ago, and was given a disk containing a program called "Mr. Potato Head", which lets users play with a computerized version of the toy character. Canter ran the program only once, and his machine was apparently infected by the virus at this time. Subsequently, the virus infected a disk of training software that Canter then delivered to Aldus; at Aldus, the virus infected disks that were then sold to customers. Although this virus was believed to be harmless, Canter reports that it forced his Macintosh II computer to shut down and caused him to lose some computer information. "My system crashed," Canter said, "I was really angry." (( Not all that surprising... quite a few popular but nonstandard programming tricks used on the classic Mac don't work on the Mac II due to its different video card/monitor architecture... many games, etc. don't run on the II for this reason and can cause some very impressive system crashes... dcp )) Canter fears that more of his customers may have been infected by the virus. MacroMind's clients include Microsoft Corp., Lotus Development Corp., Apple Computer Inc. and Ashton-Tate. Microsoft has determined that none of its software has been infected, a company spokeswoman said. Apple and Lotus could not be reached for comment. Ashton-Tate declined to comment. Aldus would not comment on how many copies of FreeHand are infected, but admits that a disk-duplicating machine copied the infected disk for three days. Half of the infected disks have been distributed to retail outlets; the other half are in Aldus' warehouse. Aldus will replace the infected disks with new, uninfected copies to any FreeHand buyer who requests it, according to Aldus spokeswoman Laury Bryant. The company will also replace the infected disks in its warehouse. (( As I recall, the DREW virus infects the System file on affected disks, but doesn't affect applications directly. I suppose that Aldus could salvage the damaged disks by replacing the System folders with copies from a locked, uninfected disk... but it'll probably be faster for them to simply erase and reduplicate. I have no idea what Canadian liability laws are like these days... but I rather suspect that if MacMag were a United States company rather than a Canadian one, its publisher would now be extremely vulnerable to a liability-and-damages suit of some sort. This escapade will probably cost Aldus a pretty piece of change in damage-control expenses and perhaps loss-of-sales or injury-to- reputation. Kids, don't try this sort of thing at home! --- dcp )) Dave Platt UUCP: ...!$ames,sun,uunet!coherent!dplatt DOMAIN: dplatt@coherent.com INTERNET: coherent!dplatt@ames.arpa, ...@sun.com, ...@uunet.uu.net ------------------------------------------------------------------------- NVIR VIRUS Vaccination by Mike Scanlin Reprinted by special permission of David Smith from MacTutor P.O. Box 400 Placentia, CA 92670 (714) 630-3730 Unless you are going to Africa or Indochina, viruses and vaccinations are not something that most of us need to worry about. However, even if you're not planning on travelling, there is one virus you need to be aware of. It is a computer virus that is infecting Macintoshes everywhere. Are you infected? Use ResEdit to open your system file and look for 'nVIR' resources. If you have them, then your system has been infected and chances are that at least some (if not most or all) of your applications are infected. Don't panic. This particular virus is relatively harmless. There is an application at the end of this article that will allow you to remove the virus from your infected applications. There is also an 'INIT' resource you can put in your System Folder that will warn you if this virus ever shows up on your system. How I found it Until last week, I had had no experience with computer viruses. I had heard rumors about the existence of Mac viruses, but didn't really believe them. I do not know when this virus first got into my system. It must have come from some program I downloaded off of a network, but I do not know which one. By the time I figured out what was going on, the virus had modified seventeen of the applications on my hard disk and my System file. Sometime near the beginning of last week, I started hearing a beep when launching programs. It didn't happen every time, only once in a while and with no discernable pattern. Using TMON, I trapped SysBeep() and discovered that something was modifying 'CODE' 0 and installing several 'nVIR' resources into every application I launched. I looked in my System file and, in addition to several 'nVIR' resources, found an 'INIT' 32 resource that I didn't put there. I compared the standard 'INIT's from an original system disk and none of them matched the 'INIT' 32 I had found. What really clued me in to the idea of a virus was that if I took the 'INIT' 32 resource out of my System file, quit ResEdit, and then relaunched ResEdit, the 'INIT' 32 resource would be back in there. After disassembling 'INIT' 32, I learned how it worked and how to make my system immune to it. I am sharing this information so that other Mac users can protect themselves as well. How to make your System file immune Use ResEdit to open your System file. Create an 'INIT' 32 resource that consists of these 2 hex bytes: 4E 75 (which is an RTS instruction). If 'INIT' 32 already exists and has a size of 366 bytes, then you can be pretty sure it is the virus' 'INIT'. Replace the existing 'INIT' 32 with the 2 byte version (4E 75). Now create 8 resources of the type 'nVIR'; the case of the resource type is important Q do not use 'NVIR' or 'nvir'. Their IDs should be 0 through 7, with size zero bytes. If they already exist, then delete them and create 8 new empty ones (with IDs 0-7). That's it. Your system is now immune to this particular virus (but not all possible viruses). If you now run an infected application, the virus will think that it is already installed in your system file, since it sees the 'INIT' and 'nVIR' resources it expects, and will leave it alone. If your System file was infected before you immunized it, you should reboot the system before using the procedure below to remove the virus from your applications. This guarantees that the effects of 'INIT' 32 are removed from memory. Removing the virus from infected applications If an application has been infected, it will have several 'nVIR' resources, a 'CODE' 256 resource, and a possibly modified 'CODE' 0 resource. Here are instructions on how to restore an infected application (note: this is only useful if you are certain that your System file is not infected. Otherwise, the applications will become infected again. Also, you should practice on a copy of an infected application): 1) Open the application with ResEdit. If 'CODE' 256 exists, use GetInfo on it to check its size. If it is 372 bytes, then remove it. The reason we check for the size is because some applications, such as ReadySetGo, already have a 'CODE' 256 resource of their own and we don't want to remove part of the application's code. 2) Open 'CODE' 0 and look at the 3rd line of 8 hex bytes (bytes 16-23). If it is "0000 3F3C 0100 A9F0" then you need to replace that line of hex numbers with the 8 bytes contained in the 'nVIR' 2 resource. If the third line does not look like the above 8 bytes, then the 'CODE' resource is probably protected and did not get modified Q see below for an explanation. In this case leave it alone. 3) Remove all 'nVIR' resources. Make sure you have completed step 2 before removing 'nVIR' 2. You cannot restore the application without it. Because this procedure is so automatic, I have written a program that does it for you. The application Vaccination displays the SFGetFile dialog and allows you to choose an application to vaccinate. A message is displayed that tells you the result of the vaccination and the SFGetFile dialog is displayed again. If your system has been infected, you should vaccinate every application on your hard drive. You will only see files of type 'APPL' in the SFGetFile dialog so you might want to do a manual tree walk of your hard drive to be sure you vaccinate all of your applications. There is no harm in vaccinating an uninfected application or in vaccinating the same application more than once. This program does not make applications immune to this virus, it only removes this virus from them. But if your System file is immune, then there is no way this particular virus can spread to your applications. Note: you cannot use the Vaccination program to make your System file immune. You will have to do that manually using the procedure above. How this virus works This particular virus modifies the 'CODE' 0 resource of an application in such a way that when you launch that application the first thing to execute is a piece of virus installation code. That installation code looks for the virus' presence in the System file you are launching from. If it does not find evidence of the virus, it then installs itself (as 'INIT' 32 and several 'nVIR' resources) into your System file and then executes the application you had originally launched. Once your System file is infected, every application launched from that system will become infected. The whole infection process only takes a second or two, so there is little chance you will notice it. If the virus detects that it is already in the System file and in the application you are launching (meaning that no installation of itself is necessary on this launch), then there is about a 6% chance (1 in 16) that you will hear a short beep. This is the beep that first got my attention. According to a friend of mine, Chris Borton, whose computer was also infected, if you have MacinTalk in your System Folder, then the virus speaks the words "Don't Panic" instead of beeping. This virus does not check if the 'CODE' 0 resource of the application it is trying to infect is protected or not. Consequently, applications that have 'CODE' 0 resources with the resProtected bit set are still infected, but are not contagious, i.e. they have the 'CODE' 256 resource and the 'nVIR' resources added to them, but they can not pass the virus on to a clean System file. I learned this by noticing that QUED/M and PageMaker were infected, but were not contagious. I couldn't figure out why some programs had protected 'CODE' resources and others didn't. Then one of the people I work with, Victor Romano, put it together. He told me that Lightspeed C (which QUED/M and PageMaker were written in) automatically sets the resProtected bit of the 'CODE' resources it generates. MPW does not. So, protecting the 'CODE' resources (which can be done with ResEdit) is another simple way of preventing this virus from affecting an application. To be forewarned I don't know how far this virus has already spread, or how far it will spread. As a partial defense, however, I have written a piece of code that can be installed as an 'INIT' file in your System Folder that will warn you if it detects something that looks like this particular virus. VirusWarnINIT is a patch on 2 routines that this virus relies on: GetResource() and ChangedResource(). The patch to GetResource() makes a beep if theType == 'nVIR'. The patch to ChangedResource() makes a beep if theResource is a handle to a 'CODE' 0 resource. I wouldn't suggest installing this 'INIT' in a system known to be infected Q the number of beeps is sure to annoy you. I would have used something like an alert window instead of a beep as a warning, but I can't be sure that the Window Manager has been initialized at the time the virus is detected. If you install this 'INIT' in a clean system and then launch a contagious application, you will hear about 5 or 6 beeps in a row as the virus tries to install itself in your System file. Note that this 'INIT' is only a warning, not a vaccination. The virus will still install itself. The advantage is that you will know about it right away and can stop it before it spreads very far. Now that my Mac has been vaccinated, it's my turn. After Typhoid, Yellow Fever, Cholera and Meningococcal vaccinations, I'm off to Africa and Indochina. I wonder if I can get David Smith to send MacTutor to Serengeti National Park? Or do they already get it there? I'll let you know... Chris "Johann" Borton, UC San Diego ...!sdcsvax!borton borton@ucsd.edu or BORTON@UCSD.BITNET Letztes Jahr in Deutschland, nog een jaar hier, en dan naar Amsterdam! "H = F cubed. Happiness = Food, Fun, & Friends." --Steve Wozniak From: jln@accuvax.nwu.edu To: info-mac@sumex-aim.stanford.edu Cc: jln@accuvax.nwu.edu Subject: nVIR A and B Message-Id: <8903162025.ac12267@accuvax.nwu.edu> There has been some confusion over exactly what the nVIR A and nVIR B viruses actually do. In fact, I don't believe the details have ever been published. I just finished spending a few days researching the two nVIR viruses. This report presents my findings. As with all viruses, nVIR A and B replicate. When you run an infected application on a clean system the infection spreads from the application to the system file. After rebooting the infection in turn spreads from the system to other applications, as they are run. At first nVIR A and B only replicate. When the system file is first infected a counter is initialized to 1000. The counter is decremented by 1 each time the system is booted, and it is decremented by 2 each time an infected application is run. When the counter reaches 0 nVIR A will sometimes either say "Don't Panic" (if MacinTalk is installed in the system folder) or beep (if MacinTalk is not installed in the system folder). This will happen on a system boot with a probablity of 1/16. It will also happen when an infected application is launched with a probability of 31/256. In addition, when an infected application is launched nVIR A may say "Don't Panic" twice or beep twice, with a probability of 1/256. When the counter reaches 0 nVIR B will sometimes beep. nVIR B does not call MacinTalk. The beep will happen on a system boot with a probability of 1/8. A single beep will happen when an infected application is launched with a probability of 15/64. A double beep will happen when an infected application is launched with a probability of 1/64. I've discovered that it is possible for nVIR A and nVIR B to mate and sexually reproduce, resulting in new viruses combining parts of their parents. For example, if a system is infected with nVIR A, and if an application infected with nVIR B is run on that system, part of the nVIR B infection in the application is replaced by part of the nVIR A infection from the system. The resulting offspring contains parts from each of its parents, and behaves like nVIR A. Similarly, if a system is infected with nVIR B, and if an application infected with nVIR A is run on that system, part of the nVIR A infection in the application is replaced by part of the nVIR B infection from the system. The resulting offspring is very similar to its sibling described in the previous paragraph, except that it has the opposite "sex" - each part is from the opposite parent. It behaves like nVIR B. These offspring are new viruses. If they are taken to a clean system they will infect that system, which will in turn infect other applications. The descendents are identical to the original offspring. I've also investigated some of the possible incestual matings of these two kinds of children with each other and with their parents. Again, the result is infections that contain various combinations of parts from their parents. John Norstad Academic Computing and Network Services Northwestern University Bitnet: jln@nuacc Internet: jln@acns.nwu.edu Applelink: a0173 ---------------------------------------------------------------------------- HPAT VARIANT OF NVIR From: alexis@ccnysci.UUCP (Alexis Rosen) Subject: Hpat virus- it is a slightly modified nVIR 'B'. Date: 7 Jan 89 10:09:44 GMT Bob Murrow sent me a copy of the Hpat virus two days ago. I have taken it apart and these are my findings. Hpat is, in essence, a slightly modified version of nVIR type 'B' (as described by myself and John Norstad). The differences are trivial: 1) The CODE resource #256, which contains most of nVIR's code, is renumbered to CODE #255. 2) Various references to CODE 256 are changed to CODE 255. 3) Various references to resource type 'nVIR' are changed to 'Hpat'. There is one minor difference that I'm not 100% sure about. It doesn't seem serious, however. In nVIR 'B', resource 'nVIR' 2 is used to hold the original jump table entry for code segment 1 (which is replaced by the virus with an entry for its own code resource). In Hpat, however, it is replaced with the following: $0200 ( possibly a segment number? ) 4EED 003A ( JMP $003A(A5) ) 4E71 ( NOP ) This looks to me like a "loaded" jump table entry for CODE 1, but I could be wrong. I believe that the JMP instruction might change, depending on the particular application infected. If I'm right, then this difference is not meaningful. Be WARNED: RWatcher, in its default configuration, will not stop an already-infected system from infecting new applications. It will, however, prevent an infected app from infecting a clean system. This is because it won't catch 'Hpat' resources or the CODE 255, but it will catch the INIT 32. To be perfectly safe you might want to edit the RLIS resource in RWatcher (a very nice INIT, by the way). One thing I wonder about: Why didn't the jerk who built Hpat modify the INIT number? If (s)he went to the trouble of changing the ID of the CODE resource and the type of the viral resources (presumably to escape the notice of protection programs), why not alter the INIT ID as well? Vaccine should catch Hpat infections (but it may crash on detection instead of putting up its dialog). In short, Hpat will be much the same pain in the ass that nVIR is, but it's not the really nasty virus of 1989. (That honor may be reserved for INIT 29 or some other undiscovered bug.) Alexis Rosen alexis@ccnysci.uucp --------------------------------------------------------------------------- AIDS VARIANT OF NVIR discovered: AIDS. [I find it a very poor joke as well] It was discovered here in the Netherlands from an application of two weeks ago, the beginning of March 1989. Thus far we have only found one department here infected (fingers crossed). It looks, after short investigation, like an exact copy of nVIR type B, the one that beeps occasionally. The resources are: Infected System file: Type ID Size -------------------- INIT 32 416 AIDS 0 2 AIDS 1 428 AIDS 4 422 AIDS 5 8 AIDS 6 66 AIDS 7 2106 Infected application: Type ID Size -------------------- CODE 256 422 AIDS 1 428 AIDS 2 8 AIDS 3 416 AIDS 6 66 AIDS 7 2106 Apple VirusRx notices the infection (due to the INIT 32) and reports a problem or an nVIR infection. Virus Detective can be easily configured to find these problems by adding "AIDS all" to the search list, and "INIT 32" if it isn't already there. The resources have been sent to John Norstad for inspection. -cbb ---------------------------------------------------------------------------- SCORES VIRUS From: jpd@eecs.nwu.edu (Phil Draughon (ACNS)) Subject: The Scores Virus Date: 18 Apr 88 16:11:09 GMT My colleague Bob Hablutzel got a copy of the Scores virus last Thursday and disassembled it, and I've been studying and testing it ever since. So far I've reverse-engineered about half the code and have a thorough understanding of how it works. This note is a preliminary report on what I know so far, after four days of research. It also outlines plans for a disinfectant program. The virus is definitely targeted against applications with signatures VULT and ERIC. I don't know if any applications with these signatures exist or are planned to be released. The virus infects your system folder when you run an infected program. The virus lies dormant for two days after your system folder is first infected. After two, four, and seven days various parts wake up and begin doing their dirty work. Two days after the initial infection the virus begins to spread to other applications. I haven't completely finished figuring out this mechanism, but it appears that only applications that are actually run are candidates for infection. After four days the second part of the virus wakes up. It begins to watch for the VULT and ERIC applications. Whenever VULT or ERIC is run it bombs after 25 minutes of use. If you don't have a debugger installed you'll get a system bomb with ID=12. If you have MacsBug installed you'll get a user break. After seven days the third part of the virus wakes up. Whenever VULT is run the virus waits for 15 minutes, then causes any attempt to write a disk file to bomb. If you don't do any writes for another 10 minutes the application will bomb anyway, as described in the previous paragraph. There's also more code to force a bomb after 45 minutes, but I can't see any way that this code can be reached, given the forced bomb after 25 minutes. The virus identifies VULT and ERIC by checking to see if the application contains any resources of type VULT or ERIC. Applications with signatures VULT and ERIC normally contain these resources, but other applications normally don't. I verified the behaviour of the virus by using ResEdit to add empty resources of types VULT and ERIC to the TeachText application. TeachText bombed as described above on an infected system, even though TeachText itself was not infected! While running my experiments I was in ResEdit on the infected system and heard the disk whir. Sure enough, ResEdit was infected. I've been running on an infected system with an infected ResEdit for three days. I reset the system clock to fool the various parts of the virus into thinking it was time for them to wake up. The Finder has also become infected. ResEdit, Finder, and the rest of the system seem to be functioning normally. Only my version of TeachText modified to look like VULT or ERIC has been affected by the virus. If you repeat any of these experiments be very careful to isolate the virus. I'm using a separate dual floppy SE to perform my experiments, and I've carefully labelled and isolated all the floppies I'm using. My main machine is an SE with a hard drive, where I have MPW and my other tools installed. It's OK to look at infected files on the main machine (e.g. with ResEqual, DumpCode, etc.), but don't run any infected applications on the main machine - that's how it installs itself and spreads. Children should not attempt this without adult supervision :-) An infected application contains an extra CODE resource of size 7026, numbered two higher than the previous highest numbered CODE resource. Bytes 16-23 of CODE resource number 0 are changed to the following: 0008 3F3C nnnn A9F0 where nnnn is the number of the new CODE resource. You can repair an infected application by replacing bytes 16-23 of CODE 0 by bytes 2-9 of CODE nnnn, then deleting CODE nnnn. I've tried this using ResEdit on an infected version of itself, and it works. The MPW utility ResEqual reports that the result is identical to the original uninfected version. The virus creates two new invisible files named Desktop (type INIT) and Scores (type RDEV) in your system folder, and adds resources to the files System, Note Pad File, and Scrapbook File. Note Pad File and Scrapbook File are created if they don't already exist. Note Pad File is changed to type INIT, and Scrapbook File is changed to type RDEV. Both of these files normally have file type ZSYS. The icons for these two files change from the usual little Macintosh to the generic plain document icon. Checking your system folder for this change is the easiest way to detect that you're infected. Copies of the following five resources are created: Type ID Size Files ----- ----- ----- ------------------------------------- INIT 6 772 System, Note Pad File, Scrapbook File INIT 10 1020 System, Desktop, Scores INIT 17 480 System, Scrapbook File atpl 128 2410 System, Desktop, Scores DATA -4001 7026 System, Desktop, Scores A disinfectant program would have to repair all infected applications and clean up the system folder, undoing the damage described above. I don't yet know exactly which files can be infected, but I know for sure that Finder (file type FNDR) can get infected, and that applications (file type APPL) can get infected. For safest results the disinfectant should examine and disinfect the resource forks of all the files on the disk. I recommend the following algorithm: Scan the entire file hierarchy on the disk, and for each file on the disk check it's resource fork. Delete any and all resources whose type, ID, and size match the table above. Delete all files whose resorce forks become empty after this operation. If the resource fork's highest numbered CODE resource is numbered two more than the next highest numbered CODE resource, and if it's size is 7026, then patch the CODE 0 resource as described above, and delete the highest numbered CODE resource. Also examine all files named Note Pad File and Scrapbook File. If their file type is INIT or RDEV, change it to ZSYS. I'm fairly confident that a disinfectant program implemented using the algorithm above would sucessfully eradicate the virus from a disk, restore all applications to their original uninfected state, and not harm any non-viral software on the disk. It should work even on disks with multiple infected system folders. I also believe that it should work even if run on an infected system, and even if the disinfectant program becomes infected itself! There's a small chance that it could delete too many resources, and hence damage some other application, but that's a small price to pay for a clean system. Getting rid of a virus is tricky, even with a disinfectant program. The disinfectant program should be placed on a floppy disk along with a system folder. Make a backup copy of this disk. The machine should be booted using the startup disk you just made, and then the disinfectant should be run on all the hard drives and floppies in your collection, including the backup copy of the startup disk you just made. Don't run any other programs or boot from any other disks while disinfecting - you might get reinfected. When you're all done, reboot from some other (disinfected) disk and immediately erase the startup disk you used to do the disinfecting, which may be (and probably is) infected itself. This should absolutely, positively get rid of all traces of the virus. The backup disk you made and disinfected should contain an uninfected copy of the disinfectant program in case you need to use it again. There are at least two red herrings in the virus. It uses a resource of type 'atpl', which is usually some sort of AppleTalk resource. As far as I can tell, however, the virus does not attempt to spread itself over networks. The 'atpl' resource is used for something else entirely. This is not a bug. Also, the virus creates the file Desktop in your system folder. This is done on purpose. It is not a failed attempt to modify the Finder's Desktop file in the root directory. The file is used by the virus, and has nothing to do with the Finder. I don't know why the virus seems to cause reported problems with MacDraw, printing, etc. Perhaps it's a memory problem - the virus permanently allocates 16,874 bytes of memory at system startup (four blocks in the system heap of sizes 772, 40, 8, and 334, and one bock at BufPtr of size 15360). I've only found one possible bug in the virus code, and it looks pretty harmless. The code is very sophisticated, however, and I can easily understand how I might have overlooked a bug, or how it might interact in strange unintended ways with other applications and parts of the system. When we've finished completely cracking this virus we'll probably distribute another report. I've posted these preliminary results now to get the information out as quickly as possible. We also hope to write the disinfectant program, if someone else doesn't write it first. I've decided not to distribute detailed information on how this virus works. I'll distribute detailed technical information about what it does and how to get rid of it, but not internal details. This was a very difficult decision to make, because normally I firmly believe in the enormous benifit of the free exchange of code and information. The Scores virus is a very interesting and complicated piece of code, I've learned a great deal about the Mac by studying it, and I'm sure other people could learn a great deal from it too. But I don't want to teach twisted minds how to write these incredibly nasty bits of code. If I write the disinfectant program, however, I will distribute its source, because I do want to teach untwisted minds how to get rid of them. So please don't bombard me with requests for more information. You may be the nicest, most honest, incredibly important person, but I won't tell you how it works. I'll make only two exceptions, and that's for a very few of my colleagues at Northwestern University, and for qualified representatives of Apple Computer. Thanks to Howard Upchurch for giving us a copy of the virus, and to Bob Hablutzel for helping me crack it. ------------------------------ Date: Tue, 26 Apr 88 10:56 CDT From: John Norstad <JLN%nuacc.acns.nwu.edu@forsythe.stanford.edu> Subject: Scores Virus Report 2 This is my second report on the Scores virus. The important good news is there are now two free disinfection programs called KillScores and Ferret 1.0. I didn't write either one of them. They seem to work fine, so there's no need for me to write another one. I'm also happy to report that CE Software's Vaccine 1.0 is effective against Scores. There's not much new to report about the virus itself. KillScores and Ferret 1.0 were posted on AppleLink over the weekend of April 16. I discovered them shortly after posting my first report on Monday the 18th. I believe they are also available on CompuServe, but I haven't checked. Both of these programs were written specifically to eradicate the Scores virus. They can also be used to simply check for the virus, without changing anything on your disk. I tested both Ferret and KillScores on my small infected test system, and on some large uninfected ones. Both of them worked on my small infected system. They removed all traces of the virus and repaired the system folder and all the damaged applications correctly. They both also correctly reported that several large systems with nearly full 20 and 80 megabyte hard drives were uninfected. A word of warning, however. My small test system only contains infected versions of TeachText, ResEdit, and MacWrite. I don't have the facilities or the time to do large scale testing of lots of infected applications. Also, I don't have the source code for either of the programs. So I can't guarantee that either of them is perfect, or that they won't damage your files. KillScores has a better user interface than Ferret 1.0, although neither one is very good. Ferret 1.0 also seems to have a problem properly reporting the names of the infected files. This only works some of the time. KillScores does a much better job of telling you exactly what it's doing. The important thing is that both of these programs seem to work, and the authors deserve our thanks. Larry Nedry wrote Ferret 1.0, and KillScores is the work of the MacPack/Apple Corps of Dallas task force, headed by Howard UpChurch. Getting rid of a virus is very tricky, even with the help of a disinfection program like KillScores or Ferret 1.0. I managed to make mistakes using them during my tests, and ended up with a system that was still infected! I recommend that you carefully follow the steps below to make sure that you've really eradicated all traces of the virus. Step 1. Make a startup disk containing just a system folder and a copy of the disinfection program (KillScores and/or Ferret 1.0). For the safest results the system folder should be copied as is from a locked original Apple system release disk. The only files you really need in your system folder are System and Finder. Make sure your system folder doesn't contain any non-Apple INITs, CDEVs, or other miscellaneous crap. Step 2. Restart your machine using the startup disk you just made. Step 3. Make a backup copy of the startup disk you just made. Step 4. Run the disinfection program on all the hard drives and floppies in your collection, including the backup copy you just made. Don't run any other programs or boot from any other disks until you're done disinfecting, or you might get reinfected. Use Finder, not MultiFinder (I've only tested under Finder. The programs might work OK under MultiFinder too, but I don't know). Step 5. Shut down your system and restart using some other (disinfected) startup disk. Step 6. Immediately erase the startup disk you made in step 1 and used to disinfect your system. The backup disk you made is free from infection, and it contains a copy of the disinfection program that you can use again if you need it. For the safest results you should try to make sure that all the files you copy to your startup disk in step 1 are uninfected. That's why I recommend using your original locked Apple release disk. I have, however, tested both KillScores and Ferret 1.0 with infected startup disks, and they seem to work OK. To double check, you can run both KillScores and Ferret 1.0. The program you run first should disinfect your disk, and the one you run second should report that the disk is free of infection. I've also tested CE Software's Vaccine 1.0 with Scores. It seems to be effective against the initial attempt at infection. In all my tests my vaccinated system bombed whenever I attempted to run an application infected with Scores, and my system was not infected. I've tried this with the "expert display" option both on and off, and with the "always compile MPW INITS" option both on and off. I've seen bombs with ID=02 and ID=25. I don't know why the system bombs instead of presenting Vaccine's usual dialog box or tiny icons. I'd like to correct an error in the first report. When fixing an infected application with ResEdit, you should replace bytes 16-23 of CODE resource 0 by bytes 4-11 of CODE resource nnnn, not by bytes 2-9. Bytes are numbered starting with 0. I apologize if this caused anybody any grief. I'd also like to thank Dave Lavery and Howard Upchurch for their early work on the Scores virus. I used their results as a starting point for my own research, and I should have given them credit in my first report. I've discovered several more interesting facts about Scores, including more attacks on VULT and ERIC, an explanation for why some applications don't get infected, and several bugs in the virus. There also may be a few problems with the disinfection algorithm I presented in the first report. The details aren't important now, so I won't describe them. It has been reported that the virus contains some sort of special code designed to fool ResEdit. This isn't true, although I have had ResEdit crash inexplicably on an infected system. John Norstad Academic Computing and Network Services Northwestern University Evanston, IL 60208 Bitnet: JLN@NUACC Internet: JLN@NUACC.ACNS.NWU.EDU ------------------------------- Date: Mon, 2 May 88 09:52 CDT From: John Norstad <JLN%nuacc.acns.nwu.edu@forsythe.stanford.edu> Subject: Scores Virus Report 3 This is my third report on the Scores virus. In my first report I revealed what Scores did, how to detect it, and how to get rid of it by hand using ResEdit. In my second report I reviewed Ferret 1.0 and KillScores, two free disinfectant programs that have appeared to get rid of Scores. In this report I describe further testing of Ferret 1.0, the new Ferret 1.1, and KillScores. IMPORTANT: Ferret 1.1 has very serious bugs! Based on my tests I recommend using KillScores instead. 1. Ferret 1.1 does NOT properly delete one of the viral resources in the system file (INIT 17), at least on my small infected test system! I found this unbelievable, so I reran my test several times, and it failed each time. Ferret 1.0 does not have this problem. 2. Ferret 1.1 does NOT properly disinfect files which contain CODE resources marked "protected". Some applications are distributed with protected CODE resources, and Scores can infect them, so this is another important bug. Ferret 1.0 also has this bug. In this case the supposedly repaired application is left in a seriously damaged state - it will bomb immediately on launch. 3. Ferret 1.1 does NOT properly disinfect locked files. This is an important bug, even though Scores can't infect locked files. The file could have been unlocked when it became infected, and then the user could have locked it later. Ferret 1.0 also has this bug. I'd like to thank Rich Holmes for first pointing out this bug. 4. Ferret 1.1 still does NOT always properly report the names of infected files. Ferret 1.0 also has this bug. To make things even worse, Ferret does not give the user any indication that anything is wrong. It leaves the user with the impression that his/her system is clean, when in fact it's still at least partially infected. I also did further testing of KillScores. KillScores had no problems with the cases above where Ferret failed - it properly disinfected all the files on my test system. In the case of locked files KillScores unlocks the file, disinfects it, and leaves it unlocked. In my second report I mentioned that CE Software's Vaccine effectively prevents infection by Scores, at least on my test system. If you are at all worried about viruses, and you should be, I strongly recommend that you get Vaccine and use it religiously. CE Software deserves all of our thanks for developing and giving away this important tool. It's not perfect protection, as the authors freely admit in the documentation, but it is effective against Scores, and I understand that it's also effective against most of the other recent Mac viruses. Once again, I must emphasize that I do not have the facilities or time to do large scale testing of many infected applications. All of my testing is done on a small floppy-only system, with only MacWrite, TeachText, and ResEdit for infected applications. So I can't guarantee that KillScores or any other program is perfect, or that I haven't made mistakes in these reports. Also, I should probably mention that all of my statements in all of my reports reflect my opinions only, and not those of my employer, Northwestern University. John Norstad Academic Computing and Network Services Northwestern University Evanston, IL 60208 Bitnet: JLN@NUACC Internet: JLN@NUACC.ACNS.NWU.EDU --------------------------------------------------------------------------- INIT 29 VIRUS 0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0 THE ELEVENTH WORD: 0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0 An Investigation Into the 712-byte RINIT 29S Macintosh Virus by Thomas Bond, Mac Consultant 11684 Ventura Blvd., #932 % Studio City, CA 91604 818-843-0567 (C) 1989 by Thomas Bond. Permission is hereby granted to distribute in whole part by any means, whether in print or electronic, as long as the name, address and phone of the author remain unchanged. Publications may quote parts for use in education on computer virus problems. Code 0 / Virus Segment \ Application Segments / ???????? ACKNOWLEDGEMENTS: This research could not have been completed without the very valuable help received from Q Tom Pitts, Robert Wright and David Lagerson of the MacValley Macintosh Users Group, Mark Weems of Kinko's Studio City store, Ken Cary of PaperWorks in Burbank, Joe Niewe of California State University, Northridge, and many others who gave up their time and advice. [MacValley membership is $30.00 per year, and provides access to the PD Library with 1000's of freeware and shareware programs, official releases of Apple System software, association with over 700 Mac users, and special presentations from software companies, covering new programs and developments in the industry. For membership info, call Bob Campbell, 818-784-2666.] BACKGROUND: This report is being prepared on January 17, 1989, for distribution at the monthly meeting of MacValley Macintosh Users Group in Burbank, California. It contains the most recent information available to the author at this time: How the new RINIT 29S 712 byte virus acts, how to detect it, how to prevent it, and how to repair the damage it may do, at least in the early stages of its infection. Those who need immediate help because they know or strongly suspect that their disks or hard disk(s) are infected, please turn to the section below labeled FOR EMERGENCY ACTION. Others may benefit from a more deliberate reading of this paper, learning how these kinds of viruses work and what to do about them. The author, Thomas Bond, is a Mac Consultant working primarily in desktop publishing and graphics, for various companies in the San Fernando Valley and Greater Los Angeles area. He is available for professional consultations regarding this or other Macintosh applications and problems by calling the number above, 24 hours. Late in December, 1988, one of my clients, the Kinko's Copy Center at Fulton Boulevard & Burbank Boulevards in Van Nuys, reported an unusual problem: It's three rental computers, all with hard disks attached, were rejecting all locked disks inserted into them. After unlocking and reinserting the disks, documents would open normally. Sometimes documents created with several programs such as PageMaker 3.0, MacWrite 5.01, Ready,Set,Go! 4.0a, Microsoft Word 3.02, Aldus Freehand 2.0, Adobe Illustrator 88, and others, would fail to print. The report from the program was either that Rthis document failed to printS or in some cases there would be a bomb, or no report at all, simply a failure to print. On occasion, the hard disk would fail to boot properly. Checks with Apple's Virus Rx 1.3 & later Virus Rx 1.4 showed only that almost all applications, the System and Finder (v. 6.0.2) were damaged. Replacement of the damaged programs and system files was performed repeatedly over a week's period. In the meanwhile, hundreds of customers used the machines and infected their diskettes. In between my own efforts, employees of the store often replaced the system files and applications themselves, in an effort to fix the problem. The hard disks were initialized several times over several days. Never-the-less, the infection reappeared immediately each time, soon after it began to be used. A few days later, similar problems began to be reported at the Kinko's Studio City store, on Ventura Boulevard near Laurel Canyon. The same procedures were followed at that store. Some of the same well-meaning but uninformed employees tried to solve the problem. In spite of the best efforts of several staff members and my own frequent visits, the equipment failed to print roughly half the time. Each store was losing 100's of dollars due to the problem, adding to $1000's. On Tuesday, January 3, I began to seriously and scientifically investigate the nature of the problem. Careful poking around in the files with ResEdit 1.2b2 had already revealed no infestation of either Scores or nVIR, with which we were sadly very familiar and expert at handling. Using ResEdit, I opened up a RcleanS and RdirtyS copy of Teach Text. The infected copy was exactly 728 bytes larger than the clean one. The CODE resource list showed ID's 0 thru 3 in the infected copy, and 0 thru 2 in the clean copy. The new resource, ID number 3, was exactly 712 bytes. The CODE resource numbered 0 was exactly 16 bytes bigger in the dirty copy than the clean copy. I became very, very concerned about the problem, as I found by using the Virus Detective* desk accessory to search for 712 byte CODE and INIT resources that there was also an INIT ID 29 installed in most documents, other INIT files such as Pyro* & Suitcase II, the System of course, the Desktop file, and all font and DA suitcase files, as well as font printer drivers such as the LaserWriter driver, and Adobe printer fonts. Some applications such as PageMaker, Freehand and Illustrator, had literally dozens of extra 712-byte CODE resources added. They grew bigger on each startup and during each boot, whether started up or not. HOW RINIT 29S WORKS: After some 57 hours of research and virus fighting labor at Kinko's 2 infected local stores, I have determined the following: 1. The INIT 29 Virus will not accept locked disks after it has been fully activated on an infected system. This is the easiest way to find out if you are fully infected. However, since this symptom does not occur immediately, you will also need to make further checks. 2. The virus first invades the Desktop file of a disk when a program is copied onto it, inserting the 712 byte INIT ID 29 resource into it. (Alternately, the INIT is added to a system file if an infected application is started up, even without being copied to the disk.) 3. On the next boot, the INIT is added to the System from the desktop file (or elsewhere, perhaps), and to every application (as a new code resource numbered one higher than the existing resource ID, and adjusted CODE ID 0 resource) that is used during that work session, and to most documents created by the infected applications during the session. 4. During the very next boot, the infected System will insert the INIT or CODE resources into every targeted file on the hard disk (or diskette), including: % The actual Desktop file of the operative system disk (hard disk or not) % INITs such as Suitcase II, Pyro*, etc. % CDEVs, RDEVs, and other system folder files % All applications and programs containing CODE resources, with Illustrator 88, Freehand 2.0 and PageMaker 3.0 getting (2) new 712 byte resources per each use or boot. Others seem to stay content to keep only one extra CODE resource. % Most document files, including those created by MS Word, MacWrite, Ready,Set,Go!, PageMaker, Illustrator, Freehand, and MS Works. Oddly, MacPaint files seemed to be free of the INIT. % All Rscreen fontS files (whether for imagewriter or laserwriter, new or old versions), all Desk Accessory files, new or old, all LaserWriter printer drivers, including those used by Cassidy, Adobe and Apple fonts, Laser Prep and Aldus Prep files, etc. 5. During invasion of an application, the INIT 29 Virus makes itself a vital part of the application, by changing the applications "jump-table" or CODE ID = 0 resource to list it as the FIRST SEGMENT TO BE RUN ON LAUNCH. The address of the next segment of CODE to be run is copied from the jump table into the virus itself. This means that removing the virus will kill the application (very much like some protoplasmic viruses). The title of this report is taken from the address of the order to run first, namely the eleventh word of the jump table, which is changed to read the new address of the virus instead of the first segment of the original program CODE. It is this word that is changed by most Mac viruses, at least so far, to ensure that they are run before any other, possibly anti-viral, instructions. SYMPTOMS OF THE INFECTION INCLUDE: % After the infected system is rebooted with the INIT running, it will not accept locked disks. It provides the alert saying that the disk suffers from minor damage and asks to repair it. You say OK and then it ejects the disk saying, of course, that the Desktop file could not be rebuilt on it. % After the infection is mature, often several days old, it begins to interrupt printing and cause documents to fail to print. This has especially been noticed with MacWrite, MS Word, PageMaker, Illustrator and Ready,Set,Go! This seems to be an intermittent problem, and can sometimes express itself very soon after infection. $Apple's own Virus Information Report says this is most likely due to the Vertical Screen Blanking Interval being used by the virus to do its work, and the work cycle of the virus running too long and interfering with the printing tasks. % Also after a mature infection of several days, the system seems to of ten fail to boot from the infected disk, giving a System Error ID 02. $Robert Wright tells me that that this is due to the Virus trying to use parts of the system which have not yet loaded into RAM. FOR EMERGENCY ACTION: % Don't rely entirely on Vaccine 1.01 from CE Software, or Apple's own VirusRX 1.4a2, or any other currently available program other than Virus Detective* DA, version 2.0 (1.2 will do, but is not as flexible, and will sometimes give false reports of removing locked or protected viral resources). % You will need to type 3 new lines of search instructions into Virus Detective* 1.2: INIT ID 29, INIT Size 712, CODE Size 712. (Virus Detective* 2.0 comes setup for several viruses including INIT 29 already.) So far, the only two programs I have found with legitimate CODE resources of 712 bytes are the fun PD programs Biorhythm and Geographic. Others you may find are most likely infected and need to be removed from your hard disk. NOTE: Simply removing the INIT is good enough from the infected non-application files, but applications will bomb if they are restarted after only removing the 712 byte CODE sections. Their jump-table, or CODE ID = 0 resource has been re-written by the virus to look for the VirusUs own CODE segment. Since the segment will no longer be there after you remove it, the System will crash with a System Error ID 15 $Robert Wright tells me this is a "segment loader" failure. If you know how to use ResEdit, you can replace words 9, 10, 11 and 12 in Code Segment 0 with words 16, 17, 18 and 19 of the top-most viral code segment. Then remove the viral code segment(s) by RclearingS them. Remember that many applications may have received many, many segments of the 712 byte viral code. The newest segment, or highest numbered one, will be the one containing the proper words for copying back into the code 0 segment. Be certain to removed all viral segments. If you are not willing or able to re-write the code using ResEdit as described here, rely on your original master disk (which should always, of course, be kept locked), and simply replace the damaged copy with another clean one. % Be sure that you do not miss a single infected file, especially the Desktop, System, Finder or INITs, CDEVs, or RDEVs. Also, check ALL your diskettes. They can be infected, even if no programs have been copied from them or to them. Simple insertion into an infected hard disk computer set-up infects them. You can then run your system again. % The Virus Detective* 1.2 desk accessory will not remove certain INIT ID 29 resources from documents and other files, since they are locked or protected by the virus. Sometimes it claims to have removed the infections EVEN THOUGH IT HAS NOT DONE SO, and sometimes it tells you it actually failed. Don't trust it completely. (Version 2.0 of the DA may do this job better, and comes fixed to look for Peace, Scores, nVIR, hPAT, and INIT 29.) Go into ResEdit and check all questionable files and clear out the locked INIT ID 29s. To encourage great Mac-ers like the author of this program, Jeffry Shulman, be sure to send him his money Q $ 20.00 is a bargain! His address is Q P.O. Box 521, Ridgefield, CT 06877-0521. I understand from talking with people in the LAMG and elsewhere that this virus is as yet not well known around LA. However, rumors of the virus have cropped up, evidently occurring some weeks ago in the Simi Valley. Members of the Canejo-Ventura area Mac Users Group reported a new virus which added INIT ID 29 to various applications on hard disks. As far as I know, no application has yet been written by their group to repair jump tables of infected applications. Of course, this report is posted on several local BBS units and 100 copies were given away at the January MacValley meeting to interested members. Communication is also being performed with other regional BBS units and interested parties in an effort to fight the growing epidemic of INIT 29 and its associated problems. FUTURE EFFORTS: We are now working on efforts to automatically detect the infection of the INIT 29 Virus and to prevent its operation. MacValley members should expect to receive further information by the next meeting, in February. Other efforts are being made to provide a program that will automatically repair infected documents, files, and applications. Until such programs are available, you would be advised to avoid using public service bureau computers for laser printing or otherwise WITHOUT FIRST LOCKING YOUR DISKETTES, then copying the data onto their hard disks for revision or printing. If your locked disk is rejected, DO NOT UNLOCK IT. You may unlock it, and try to copy it, print it and or revise it on their hard disk. DO NOT RECOPY THE REVISED VERSION OF YOUR FILE TO YOUR DISK unless you are willing to accept the consequences of an infection at home. NOTE: Some document files after infection fail to copy, due apparently to their "protect" bit being set by the virus. This is the cause of much frustration at such service bureaus. FURTHER REPORTS OF INFECTIONS, NEW VIRUS SYMPTOMS, ETC.: Any further information, elaboration on the symptoms, or other virus reports would be appreciated . Call Thomas Bond at 818-843-0567, or David Lagerson, MacValley President, at 818-882-4467. --------------------------------------------------------------------------- ANTI VIRUS This is a report on the ANTI Virus. For any information, please contact me directly at the following address: Danny Schwendener ETH Macintosh Support, ETH-Zentrum, m/s PL, CH-8092 Zuerich, Switzerland UUCP: macman@ethz.uucp BITNET: macman@czheth5a.bitnet Internet: macman@ifi.ethz.ch AppleLink: macman%czheth5a.BITNET@DASNET# Note: This is an extract of the full report. Sensitive information has been removed. The full report has been sent to known authors of virus detectors and vaccines. Please distribute this version of the report as widely as possible. I don't have access to CompuServe, GEnie or CalvaCom. A. HISTORY The virus initially appeared in France. So far, it has been signaled in Paris, Marseille and a few other places in France. Thierry Lalettre, chief moderator of the Macintosh forum in CalvaCom, alerted by user contributions in his forum, posted a warning to CompuServe and mailed samples of the virus to a few authors of macintosh vaccines and viral detectors, including myself. Note: CalvaCom (formerly Calvados) is Europe's largest commercial electronic conferencing system, in the same spirit as CompuServe or GEnie, but mainly directed at owners of Apple products. B. OVERVIEW The ANTI Virus is a program that attaches itself to the end of the main code resource of an application. It patches the main code so that it is invoked in the first place each time the application is started. An infected application will try to infect the system heap, if it wasn't already infected beforehand (the system heap means the part of the system that has been loaded into memory at boot-time. ANTI does *not* infect the file 'System'). The virus does nothing hazardous besides propagating itself. It is less contagious than the INIT29 virus, but more than nVIR. The hypothesis made by Thierry Lalettre, stating that Apple France Developer Support Manager Alain Andrieux' program 'Stamp 1.0b5' has been purposely recompiled by an unknown person to include special infection code, is wrong. A disassembly of all resources in the application only showed up that it was infected in a normal way by the ANTI virus. Thierry also stated that the virus only attacks applications with CODE ID=1 named "Main". This is not correct. Actually, the virus propagates to all applications whose main code entry starts with a JSR. Most compilers create this type of applications, and some of them, including MPW, name the CODE ID=1 resource "Main". Under certain circumstances, the virus also propagates to all other kind of applications (i.e. the ones which don't start with a JSR). The virus assumes that the main program entry of the application to infect is contained in CODE ID=1. This is the case in all normal applications. Applications whose main routine is contained in a CODE resource different from ID=1 will either not be infected or crash. Portions of the code suggest that the virus has been written as part of a copy-protection scheme. C. DETECTION <some stuff removed> The virus can be detected by several means: - it adds 1344 bytes to the CODE ID=1 resource of the file. An infected application will have grown by 1K. The modification date is changed to the date and time of the infection. - it contains seven occurrences of the hex sequence $16252553. The last occurrence of this sequence is located 43 bytes before the end of the CODE ID=1 resource. The virus uses this sequence to detect if a System or an application has already been infected. - the virus also contains a 9-char. pascal string 'ANTI ' (hence its name) followed by the hex sequence. The 9-byte string is followed by the pascal string '#000000'. - it patches _MountVol and _OpenResFile. Trap watcher programs like GateKeeper, RWatcher or Vaccine will successfully prevent infections. There is however a restriction with Vaccine: As the virus temporarily uses the pointer to the global variables (A5) for internal tasks, Vaccine will not be able to access the screen to display a warning alert. If the option "Always compile MPW INITs" is unchecked, it will beep and wait that the user presses 'y' (allow resource copy) or 'n' (don't allow copy). If the option is checked, Vaccine will allow the infection without warning the user. So be careful if you use that option. The next release of VirusDetective will be able to find this kind of virus by looking for specific hex sequences. D. REPAIR Note: I personnally don't endorse this. Badly repaired applications may cause much more harm than the virus itself could ever do. An infected application should be deleted. I'm including this information for those who forgot to backup their disks. The virus starts with the following hex sequence: 000000: 6000 0028 0000 0000 1625 2553 0723 3030 000010: 3030 3031 0941 4e54 4920 1625 2553 0723 000020: 3030 3030 3030 xxxx xxxx xxxx xxxx contains the saved values for the instruction words that have been patched by the virus. To repair an application: 1- Be sure you're working in a clean environment (uninfected Finder and ResEdit). 2- Open the CODE ID=0 resource. Write down the word at position 16 (first word of the third line if opened with ResEdit). This value tells you at what position within the CODE ID=1 resource you have to look for the patch, and is usually $0000. 3- Search in the CODE ID=1 resource for the hex sequence I described above. write down the value I noted as 'xxxx xxxx'. 4- Still in CODE ID=1, find the location of the patch, with the value you found in step 2. The first word of the patch should be $4EBA. 5- Replace the patch by the two words you found in step 3. 6- Remove the whole virus code (everything from the virus start to the end of the resource). This step is not absolutely necessary. D. INTERNAL WORKINGS <lots of text deleted> The _MountVol patch works as follows: - Call original _MountVol - Check if mounted volume is a floppy drive. If not, exit. - Check if floppy is old (400K) or new (800K) and if the disk is single-sided or a double-sided. According to the result, read in either logical block 192 or 384. - check for our hex sequence in position 8 of the block. If found, JSR to the code in position 0 of the sector, then exit. Note: The virus does not contain any portion of code that writes something directly to a logical block. Also, the code that will be executed if the search is successful is not known at this point. This routine has a strong ressemblance to existing copy-protection schemes. It is very possible that the virus is part of a copy-protection. I won't comment on copy-protection per se, but I find using viruses as part of a product's protection scheme extremely unethical.